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(54) Procede et systeme d'administration de reseaux et de systemes 


(57) La presente invention concerne un procede et 
un systeme d'administration de reseaux et de systemes. 

Le procede d'administration d'un reseau est carac- 
terise en ce qu'il comprend au moins un sous-adminis- 
trateur (COACH) situe dans I'arbre de contenance entre 
un administrateur principal (AD) et les equipements du 
reseau, le sous-administrateur etant localise sur le re- 


seau local d'entreprise (RLE), administrant un sous-re- 
seau et comprenant differents modules qui communi- 
quent entre eux et avec un administrateur principal (AD) 
par I'intermediaire d'un noyau (N), les modules interro- 
geant les equipements du sous-reseau et recevant les 
alarmes lancees par les agents (snmp) fonctionnant sur 
les equipements du sous-reseau. 
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Description 

[0001] La presente invention concerne un procede et un systeme d 'ad ministration de reseau et de systemes. 
[0002] Les grandes entreprises ont un nombre croissant d'equipements a gerer. Ces equipements, relies entre eux 

5 par un reseau de communication appele "Reseau Local d'Entreprise" (RLE, LAN), sont administres par un adminis- 
trates. Pour administrer (controler, agir, surveiller, piloter) a distance des equipements a partir d'un point, le modele 
d'architecture comportant un administrates, par exemple. (ISM, figure 4) et un agent, par exemple, type SNMR est le 
plus couramment adopte. Dans ce modele d'architecture : les agents (SNMP), implementes sur les equipements (ET) 
du reseau, renseignent I'administrateur sur I'etat de chacun des equipements administres. Lors de chaque dysfonc- 

10 tionnement d'un equipement, un agent (snmp) envote, a I'administrateur, une alarme a travers le reseau grande dis- 
tance (WAN). Dans la grande majorite des cas, cet administrateur gere plusieurs centaines d'equipements repartis sur 
un ou plusieurs pays. Les informations echangees entre I'administrateur et les equipements administres circulent a 
travers un reseau grande distance aussi appele "WAN" (Wide Area Network). Cependant, le reseau WAN a des ca- 
pacites limitees et la transmission des informations a travers ce reseau est aujourd'hui lente et peu sure. Ce probleme 

'5 s'explique par le fait que la bande passante du reseau (WAN) est trop reduite par rapport au nombre d'informations 
toujours croissant devant transiter entre les administrateurs et leurs equipements. Les reseaux locaux supportent 
souvent un trafic superieur a 10 Megabits, alors que le reseau WAN a une largeur de bande souvent inferieure ou 
egale a 64 Kilobits : 9600 bauds est une valeur courante. En consequence, le reseau (WAN) est sursature et beaucoup 
d'informations sont perdues. D'autre part, la transmission des donnees est tres lente et le type d'envoi (par petits 

20 paquets periodiques) n'est pas adapte aux modes courants d'utilisation des WANS. Le traitement des informations par 
I'administrateur est ralenti et les actions correctrices a declencher sont tardives. De plus : dans certains cas, la chro- 
nologie des arrivees des informations a I'administrateur n'est pas respectee a cause de ce flux trop important. Dans 
ce cas, le traitement de ces informations peut donner lieu a une mauvaise interpretation des fails qui peut declencher 
des actions inadequates de la part de I'administrateur Le cout des communications est, par ailleurs, eleve. 

25 [0003] Une solution au probleme de perte d'informations consiste en ce que I'administrateur genere a travers le 
reseau (WAN), a une periode donnee, une requete de la forme "Est-ce que tu vas bien ?" vers chaque systeme ad- 
ministre et que ces derniers repondent "Oui, je vais bien". Cette solution est tres couteuse. Elle ne resout pas le 
probleme de sursaturation des cables et augmente encore les flux d'informations a travers le reseau (WAN). En outre, 
la requete ou la reponse a cette requete peut se perdre dans le reseau (WAN). 

30 [0004] Une autre solution consiste a gerer les flux d'informations a Caide d'outil tel que SM Monitor 6000 propose 
par la marque IBM. Cet outiL fortement lie a la plate-forme appelee "System View", est deporte et permet de concentrer 
les alarmes d'un reseau et d'effectuer des operations a partir des informations que peuvent fournir les agents du reseau. 
Mais. SM Monitor 6000 est consommateur d'unite centrale de traitement (CPU, Control Processing Unit) et prend une 
place importante en memoire. De plus, aujourd'hui, un grand nombre d'entreprises a besoin de gerer des petits reseaux 

3$ en grand nombre. Or, SM Monitor 6000 ne possede pas de mecanisme de deptoiement a grande echelle et ne peut 
done pas etre utilise pour la gestion d'un grand nombre d'equipements. En outre, SM Monitor 6000 a une technologie 
peu portable. La configuration de SM Monitor 6000 ne peut s'erfectuer qu'avec la plate-forme "System View" et est 
inexploitable sans cet outil. 

[0005] Une derniere solution, proposee par la societe "BMC software", consiste en un module de controle qui permet 
40 de surveiller un ensemble d'agents appeles "agents Patrols". Un agent Patrol peut contenir plusieurs modules, chacun 
ayant pour fonction de recolter un certain type d'informations tel que les informations du systeme ou les informations 
d'une application (par exemple, d'une base de donnees Oracle). Cette solution n'est pas adaptee. En effet, bien que 
la technologie Patrol permette de recolter certaines informations sur les equipements, elle n'est pas concue pour 
assurer un role d'administrateur vis-a-vis d'agents. L'agent Patrol traite des donnees locales sur une machine, il n'est 
•ts qu'une source d'informations et ne s'alimente pas de donnees en provenance d'autres agents. En outre, la capacite 
a gerer le changement sur les equipements est ignoree par I'approche de Patrol, alors qu'etle est fondamentale en 
exploitation. De plus, elle est consommatrice de temps et moyens CPU des systemes cibles a cause de la technologie 
par langage interprets. 

[0006] La presente invention a pour but de pallier des inconvenients de Tart anterieur en proposant un procede 
50 portable d'administration de reseaux adapte a I'administration d'un grand nombre d'equipements. Le procede selon 
('invention, limite et securise le flux d'administration entre I'administrateur et les equipements administres en evitant 
('envoi de messages non necessaires ou la repetition de renvoi d'un meme message dans le reseau WAN. Ce procede 
s'adapte ainsi, aux saturations de la bande passante et permet de reduire les pertes d'informations dans le reseau 
(WAN). De plus, grace a ce procede, les frequences de recolte d'informations sont adaptables, information par infor- 
ms mation, et tes donnees recoltees par le systeme sont reutilisables a tout moment pour effectuer des statistiques , pour 
surveiller les performances des equipements ou encore pour eviter d'ailer rechercher plusieurs fois la meme informa- 
tion. D'autre part, ce systeme s'auto-instruit de son environnement. La prise en compte de milliers d'equipements se 
fait automaliquement malgre des conlextes Ires differents. L'apparition ot la disparition de systomos olomontairos sont 
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dynamiquement prises en compte au cours de I'exploitation. sans intervention de i'operateur. Enfin, I'invention permet 
une diminution de la charge de traitements d'informations au niveau du controle. 

[0007] Ce but est atteint par le fait que le procede d'administration d'un reseau comprend au moins un sous-admi- 
nistrateur (COACH) situe dans I'arbre de contenance entre un administrateur principal (AD) et les equipements du 
s reseau, le sous -administrateur est localise sur le reseau local d'entreprise (RLE), administre un sous-reseau et com- 
prend differents modules qui communiquent entre eux et avec un administrateur principal (AD) par I'intermediaire d'un 
noyau (N) : les modules interrogeant les equipements du sous-reseau et recevant les alarmes lancees par les agents 
(snmp) fonctionnant sur les equipements du sous-reseau : le procede etant compose de plusieurs etapes : 

10 - une etape pendant laquelle un module de decouverte (MD) interroge tous les equipements (ET) possibles du sous- 
reseau, 

une etape de recherche de domaine par le module de decouverte (MD), lorsqu'un equipement repond a I'interro- 
gation (SNMP), 

une etape pendant laquelle le module de decouverte (MD) envoie une notification a un module de configuration 
is des modeles (MCM) lui indiquant I'adresse internet (IP) de I'equipement decouvert et le domaine auquel I'equipe- 

ment decouvert appartient, 

une etape pendant laquelle le module de configuration des modeles (MCM) notifie a un module de calcul d'indi- 
cateurs (MCI), I'indicateur a instancier sur I'equipement et a un module de filtrage d'alarmes (MFA) le modele de 
filtre a instancier sur 1'equipement. 

20 

[0008] Selon une particularity de I'invention, le procede d'administration d'un reseau est caracterise en ce qu'a cha- 
que nouvelle etape de decouverte des equipements du sous-reseau, le module de decouverte (MD) met a jour les 
bases de donnees du noyau (N) et du module de configuration des modeles (MCM) contenant la liste des equipements 
et de leurs domaines. 

25 [0009] Selon une autre particularity toutes les alarmes emises par les differents modules sont envoyees a Tadmi- 
nistrateur principal (AD) via le module de securisation d'alarmes (MSA), ladite alarme etant accompagnee d'un mes- 
sage d'envoi destine au serveur du module de securisation d'alarmes (sMSA). 
[0010] Selon une autre particularity le procede d'administration d'un reseau est compose: 

30 - d'une etape de reception de I'alarme par I'administrateur principal (AD) et de reception dudit message d'envoi par 
le serveur du module de securisation d'alarmes (sMSA)., 

d'une etape d'envoi d'un message de confirmation de reception par le serveur du module de securisation d'alarmes 
(sMSA) au client du module de securisation d'alarmes (cMSA), 

d'une etape de reception du message de confirmation de reception par le client du module de securisation d'alar- 
35 mes (cMSA), 

d'une etape de mise a jour des instances d'alarmes stockees dans le module de filtrage d'alarmes (MFA). 

[0011] Selon une autre particularity lorsque le client du module de confirmation d'alarmes (MCA) n'a pas recu le 
message de confirmation de reception, il renvoie, apres un temps determine, I'alarme a I'administrateur principal (AD). 

•to I'alarme etant accompagnee d'un message d'envoi destine au serveur du module de securisation d'alarmes (sMSA). 
[0012] Selon une autre particularity lorsque le module de calcul d'indicateurs (MCI) ou le module de decouverte 
(MD) n'obtient pas de reponse a une requete envoyee a un equipement du sous-reseau, le module de calcul d'indica- 
teurs (MCI) ou le module de decouverte (MD) envoie un message a un module chien de garde (MCG) : le module chien 
de garde (MCG) interrogeant I'equipement suppose disparu et attendant de maniere plus longue, une reponse. 

is [0013] Selon une autre particularity lorsque, apres un temps determine, le module chien de garde (MCG) n'obtient 
pas de reponse de I'equipement suppose disparu, I'equipement est supprime de la base de donnees du noyau (N). 
de la base de donnees du module de decouverte (MD) et de la base de donnees du module de configuration des 
domaines (MCM), le module chien de garde (MCG) envoyant une alarme a I'administrateur principal (AD), lui indiquant 
la disparition de I'equipement, I'alarme etant percue par I'administrateur comme provenant de I'equipement et envoyee 

50 en utilisant le module de securisation. 

[0014] Selon une autre particularity lorsque le module chien de garde (MCG) obtient une reponse de I'equipement 
suppose disparu, il demande la redecouverte des domaines, si la demande a ete emise par le module de calcul d'in- 
dicateur. 

[0015] Un autre but de ('invention est de fournir un systeme d'administration de reseaux et de systemes. 
55 [0016] Ce but est atteint par le fait que ce systeme d'administration d'un reseau par un administrateur principal 
communiquant avec des equipements (ET) a travers un reseau grande distance (WAN) et des reseaux locaux d'en- 
treprises (RLE) est caracterise en ce qu'il comprend au moins un sous-administrateur (COACH) localise sur le reseau 
local d'entreprise (RLE) et administre par I'administrateur principal (AD). Le sous-administrateur (COACH) comportant 
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des moyens d'interroger les equipements du reseau local d'entreprise (RLE), de filtrer et de stocker les alarmes iancees 
par les agents (snmp) fonctionnant sur les equipements du reseau, des moyens de securiser les alarmes envoyees a 
I'administrateur principal (AD) et un moyen de dialogue avec I'administrateur principal et entre les differents moyens. 
[0017] Selon une particularity de I'invention, le moyen de dialogue est constitue d'un noyau (N) dialoguant avec 
5 I'administrateur principal (AD) et permettant le dialogue entre les differents modules composant ledit systeme, Selon 
une autre particularite. les moyens d'interroger les equipements du reseau local d'entreprise (RLE), de filtrer et de 
stocker les alarmes Iancees par les agents (snmp) fonctionnant sur les equipements du reseau sont constitues 

d'un module de decouverte (MD) decouvrant les equipements (ET) du sous-reseau a administrer et classant lesdits 
io equipements dans des domaines en fonction des types d'agents qui y sont installes. Ce module de decouverte 

amplifie la fonction de decouverte de I'administrateur central, par une precision accrue, une decouverte plus rapide 
et une economie considerable en bande passante. 

d'un module de configuration de modeles (MCM) comportant des modeles de filtre d'alarmes et des indicateurs 
pouvant etre instancies sur les equipements du sous-reseau, chaque indicateur etant associe a une periode d'in- 
*s terrogation, 

d'un module de calcul d'indicateurs (MCI) calculant le resultat de I'application d'un indicateur a un equipement, 
I'indicateur etant defini pour le domaine auquel I'equipement appartient, le resultat de cette application etant com- 
pare a une valeur seuil ne devant pas etre depassee un certain nombre de fois, pendant un certain laps de temps, 
d'un module de filtrage d'alarmes (MFA) recevant les alarmes envoyees par les agents (snmp) fonctionnant sur 
20 (es equipements du sous-reseau. puis, selectionnant une partie desdites alarmes a I'aide d'un filtre defini pour un 

domaine donne, lesdites alarmes selectionnees etant re-emises vers I'administrateur principal (AD), 

[0018] Selon une autre particularite, les moyens de securiser les alarmes envoyees a I'administrateur principal (AD) 
sont constitues : 

25 

d'un module de chien de garde (MCG) qui, lorsqu'un module le lui demande, verifie I'existence d'un equipement 
par renvoi repete d'appels, si I'equipement disparu n'a pas repondu a un nombre predefini d'appels, ledit module 
chien de garde (MCG) envoie une alarme a I'administrateur principal (AD) qui sera percue par ce dernier comme 
provenant de I'equipement disparu, 

30 - d'un module de securisation d'alarmes (MSA) fonctionnant selon le mecanisme client-serveur, le client (cMSA), 
lors de I'envoi d'au moins une alarme a I'administrateur, attendant un message de confirmation du serveur (sMSA) 
localise sur I'administrateur principal (AD), ledit serveur (SMSA), apres reception dudit message d'envoi, envoyant 
un message de confirmation de reception au client (cMSA), le client renvoyant I'alarme et un autre message d'envoi 
a administrateur lorsque, apres un temps determine, le message de confirmation de reception n'est pas recep- 

35 tionne par le client. 

[0019] Selon une autre particularite, lorsque la valeur seuil est depassee un certain nombre de fois pendant un 
certain laps de temps, le module de calcul d'indicateurs (MCI) emet une alarme vers I'administrateur principal (AD), 
ladite alarme etant percue par I'administrateur principal comme etant emise par I'equipement dont I'instanciation a ete 
■*o effectuee. 

[0020] Selon une autre particularite, un indicateur est une equation appliquee a des instances d'objets d'une base 
de gestion d'informations (MIB), les instances etant obtenues par une interrogation des agents (SNMP) fonctionnant 
sur chacun des equipements du sous-reseau. 

[0021] Selon une autre particularite, le resultat d'un indicateur et/ou une liste des alarmes envoyees peut etre stocke 
dans un fichier archive sur le disque dur. 

[0022] Selon une autre particularite, le parametrage des filtres d'alarmes s'effectue soit par un fichier d'initialisation 
soit via le protocole snmp. 

[0023] Selon une autre particularite, les alarmes a envoyer sont accumulees par le module de confirmation d'alarmes 
afin de les envoyer groupees, par paquet, a une frequence donnee. 
50 [0024] Selon une autre particularite, un modele de filtre d'alarmes contient une description de I'alarme a reconnaitre 
et un nombre maximal d'occurrence d'alarmes avant lequel une autre alarme est emise vers I'administrateur principal 
(AD), si ledit nombre maximal d'occurrence d'alarmes est re<pu pendant une certaine periode. 

[0025] Selon une autre particularite, les differents modules interrogent le noyau (N) pour initialiser leurs parametres 
de fonctionnement. 

55 [0026] Selon une autre particularite. le noyau (N) gere une base de donnees contenant toutes les instances de la 
base de gestion d'informations (MIB), ledit noyau comportant au moins deux supports (sockets) de communication et 
une interface commune de gestion de la communication avec les modules. 

[0027] Solon uno autre particularity les parametres d'initialisation du modulo do docouvorto (MD) comportant Va 
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periode espacant deux decouvertes, le nombre minimum de systemes a decouvrir et le masque du protocole internet 
(IP) determinant I'etendue du reseau a decouvrir. 

[0028] Selon une autre particularity un equipement (ET) decouvert est classe dans un ou plusieurs domaines en 
fonction de ses reponses aux interrogations effectuees sur chaque ensemble d'instances d'objets de la base de gestion 
5 d'informations (MIB) definissant un domaine. 

[0029] D'autres particulates et avantages de la presente invention apparaitront plus clairement a la lecture de la 
description ci-apres faite en reference aux dessins annexes dans lesquels : 

la figure 1 represente un exemple d'implementation du procede d'administration de deux sous-reseaux. 
10 - la figure 2 represente ('architecture du systeme d'administration, 

la figure 3 represente un exemple d'implementation du procede d'administration de n sites, 
la figure 4 represente un systeme d'administration classique. 


[0030] La presente invention propose un procede et un systeme de gestion de reseaux totalement parametrables a 
15 distance via un protocole standard : le protocole SNMR Comme le montre la figure 1 , le systeme d'administration de 
reseau est compose d'un administrateur (AD1) et d'au moins un sous-reseau local (RLE1 ; RLE2) relie a un agent 
ouvert central pour une administration concentree (COACH, Central Open Agent for Concentrated Handling). Le sous- 
administrateur (COACH1) agit a un niveau intermediate d'administration. Situe sur le reseau local d'entreprises 
(RLE1) : il permet de limiter le flux d'administration entre I'administrateur principal (AD1) et les equipements (ET) du 
20 reseau (RLE1). II est percu par les equipements du reseau comme un administrateur et par I'administrateur comme 
un equipement. 

[0031] Le sous-administrateur (COACH), tel que represente en figure 2, comporte un ensemble de processus aussi 
appeles "modules" qui dialoguent les uns avec les autres et avec I'administrateur principal (AD) par I'intermediaire d'un 
processus central aussi appele "noyau" (N). Les dialogues entre les differents modules se font par un support (socket) 

2S portable et standard. Chaque module est dedie a une fonction precise. 

[0032] Le module central ou noyau (N) a deux fonctions principals. D'une part, il dialogue avec I'administrateur 
(AD) et d'autre part, il gere le dialogue entre les differents modules composant le sous-administrateur (COACH). En 
effet, le noyau (N) repond au dialogue (snmp) ; lorsque le sous-administrateur (COACH) est interroge ou configure par 
I'administrateur. II existe deux types de dialogue avec les modules, c'est pourquoi deux supports (sockets) de com- 

30 munication sont souhaitables pour gerer le dialogue noyau-module. Le premier type de dialogue se fait a I'initiative du 
noyau et concerne les mises a jour d'instances ou les demandes d'informations sur une base de gestion d'informations 
(MIB) ou les transmissions de notifications provenant d'un autre module. Le second type de dialogue se fait a I'initiative 
des modules et concerne les demandes d'informations ou les mises a jour d'instances de la base de gestion d'infor- 
mations (MIB). Le noyau gere deux listes de supports. La creation de support dans chacune de ces listes se fait 

35 dynamiquement lors de la connexion des modules. Pour le dialogue (snmp) avec I'administrateur le standard impose 
('utilisation d'un seul support (socket). Le dialogue se fait sur le port 161/udp. mais I'utilisation d'un dispatcher de 
requetes necessite ('utilisation d'un autre port parametrable afin d'avoir la possibility de faire fonctionner plusieurs 
agents (snmp) sur un meme equipement. Pour simplifier la gestion de communication avec les modules, une interface 
commune est definie sous forme de librairie. Par ailleurs, le noyau (N) possede une memoire cache (cache memory) 

•*o (C) contenant toutes les informations resultant de Padministration d'un sous-reseau (RLE). Chaque module interroge 
le noyau pour initialiser ces parametresde fonctionnement. En outre, le noyau (N) gere une basede donnees contenant 
toutes fes instances de la base de gestion d'informations (MIB) du sous-reseau admin istre par le sous-administrateur 
(COACH). 

[0033] Le module de decouverte (MD) decouvre le sous reseau (RLE 1) sur lequel est installe le sous-administrateur 
-i5 (COACH11). A I'aide d'une table des masques d'adresse du protocole internet (IP. Internet Protocol), le module de 
decouverte (MD) determine les adresses (IP) des equipements (ET) que le sous-administrateur peut eventuellement 
administrer. Puis, le module de decouverte (MD) interroge successivement par groupe de paquet internet (PING Packet 
Internet Groper) unitaire tous les equipements possibles. Le PING est une interrogation standard que Ton peut utiliser 
pour savoir si une machine est connectee sur le reseau Internet, pour determiner la provenance d'un message ou pour 
50 verifier si un systeme est toujours en activite. Lorsqu'un equipement est visible sur le reseau, il repond au PING. 

[0034] Si un equipement est decouvert, le module de decouverte (MD) recherche son domaine. Chaque equipement 
appartient a un domaine. Le domaine de chaque equipement permet de definir des groupes d'indicateurs et de filtres 
d'alarme a injecter sur chacun des equipements et ceci, en fonction des agents presents sur ces equipements et done 
en fonction des roles depourvus a chaque equipement. 
55 [0035] Le domaine d'un equipement est defini selon la reponse ou non de I'equipement a un ensemble d'instances 
d'objets de la base de gestion d'informations (MIB snmp). Des la decouverte d'un nouvel equipement, une interrogation 
(polling) est effectuee sur un ensemble d'instances d'objets (snmp). Lorsqu'un equipement (ET) decouvert repond aux 
interrogations de toutes les instances d'objets definissant un domaine, on dit que I'equipement appartient a ce domaine. 
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Tous les equipements decouverts sont classes selon des domaines. Ces domaines permettent de differencier les 
differents types d'equipements et d'administrer differemment chacun des equipements selon son domaine. Un equi- 
pement peut appartenir & plusieurs domaines. 

[0036] Le domaine MIB2 pourrait, par exemple, etre defini par la reponse a I'instance "sysUpTimeO". Tous les equi- 
5 pements decouverts sont interroges sur cette instance. Ceux qui y repondent appartiennent au moins au domaine Ml B2. 
[0037] Enfin, lorsque le module de decouverte (MD) a decouvert un equipement et son domaine, il envoie une no- 
tification a un module de configuration des modeles (MCM) en lui indiquant I'adresse du protocole internet (IP) de 
I'equipement decouvert et le domaine auquel cet equipement appartient. Avantageusement, le module de decouverte 
(MD) envoie. de plus, ces memes informations au noyau (N) qui les stockera dans une base de donnees. 
w [0038] Generalement, lorsqu'un systeme existant est decouvert une seconde fois : son domaine n'est pas, a nouveau, 
recherche. Neanmoins, le domaine d'un systeme peut etre recherche en positionnant sur "actif (ON) ['instance de la 
base de gestion d'informations (MIB) relative a ta decouverte des domaines. Dans ce cas sL le domaine n'est pas le 
meme que le precedent, la base de donnees du noyau est automatiquement mise a jour et des notifications sont 
automatiquement envoyees au module de configuration des modeles (MCM). 
'5 [0039] Lorsqu'un equipement precedemment decouvert ne repond plus k un PING unitaire, le modele de decouverte 
(MD) envoie une notification a un module (MCG) chien de garde (Watchdog) afin qu'il verifie si I'equipement a reellement 
disparu du reseau. 

[0040] Des sa connexion, le module de decouverte (MD) interroge le noyau (N) afin de connaitre ses parametres 
d'initialisation: 

20 

la periode entre deux decouvertes successives, 
le nombre minimum de systemes k decouvrir, 

le masque du protocole internet (IP) determinant I'etendue du reseau a decouvrir. 

25 [0041] Le module de decouverte comporte des elements de configuration de base : un ensemble distances d'objets 
de la base de gestion d'information (MIB) a interroger et la liste des systemes decouverts ainsi que leurs domaines. 
[0042] L'annexe 7 presente un modele de configuration de la decouverte. L'annexe 8 presente les donnees dyna- 
miques de decouverte. 

[0043] Le module de filtrage d'alarmes (MFA) regoit les alarmes (traps) envoyees par les agents (snmp), implementes 
30 sur les equipements (ET) et filtre les alarmes a reemettre vers I'administrateur principal (AD). Des la reception d'une 
alarme, ce module tente de reconnaitre dans quel domaine appartient I'equipement (ET) qui a envoye cette alarme. 
Ce renseignement lui permettra de determiner le modele de filtre a appliquer a cette alarme. Un modele de filtre 
d'alarmes est defini par une description de I'alarme a reconnaitre (champs SNMP de description: Entreprise, generique, 
specifique) et par un nombre maximal d'occurrence d'alarmes pendant une certaine periode avant lequel une autre 
35 alarme est emise. Le choix du modele de filtre se fait en fonction du domaine auquel I'equipement envoyant une alarme 
appartient. Lorsqu'une alarme n'est pas reconnue, elle est transmise a I'administrateur principal (AD). De plus, la 
premiere instance d'alarme recue est toujours emise vers I'administrateur principal (AD). Par exemple, pour un equi- 
pement appartenant au domaine "Imprim", c'est-a-dire une imprimante, un modele d'alarme indiquant "plus de papier 
dans rimprimante" est defini. Ce modele est instancie sur toutes les imprimantes du sous-reseau. Le modele de filtre 
-to de cette alarme est decrit comme une alarme de niveau 0, envoye a I'administrateur (AD). Ainsi, si I'un des agents 
des imprimantes emet cette alarme, le module de filtrage d'alarmes (MFA) ne transmettra aucune de ces alarmes a 
I'administrateur principal (AD). Si : ces memes imprimantes emettent une alarme de dysfonctionnement revelant un 
"probleme reseau" et que le modele de filtre de cette alarme est decrit comme etant de niveau 1 sur 50 en moins de 
30 minutes, signifiant qu'il faut reemettre une alarme lorsque cinquante alarmes ont ete recues en moins de trente 
minutes, le module de filtrage d'alarmes (MFA) reemettra pour chaque imprimante la premiere alarme recue, puis 1 
sur 50 dans une periode de 30 minutes. Si seulement deux alarmes arrivent a au moins trente minutes d'intervalle, 
elles seront toutes les deux transmises. 

[0044] Le module de filtrage d'alarmes (MFA) est aussi a I'ecoute du noyau (N). Ce dernier lui envoie des notifications 
de mise a jour de modele de filtre d'alarmes. Les donnees contenues dans le module de filtrage d'alarmes (MFA) sont 
50 la description des modeles et des informations sur les instanciations de ces modeles (date de la premiere instance 
d'alarme recue. nombre d'alarmes recues pendant la periode critique). 

[0045] En outre, renvoi d'alarmes peut etre archive dans un fichier sur le disque dur par I'emploi de la fonction "set" 
et I'administrateur peut le recuperer avec, par exemple, un protocole de transfert de fichiers (FTP, File Transfert Pro- 
tocol). Les informations ainsi archivees concernent la date, I'enterprise, le generique et le specifique d'une alarme 
55 emise. Un envoi d'alarme peut, par exemple, etre trace sous cette forme: Nov 19 19:32 1997: 1.3.6.1.4.1.107.144:6: 
1. Cette information doit etre interpretee sous cette forme : le 19 novembre 1997, a 19h32, une alarme d'enterprise 
1.3.6.1 .4.1 .107. 144 de type generique 6 et specifique 1 a ete emise vers I'administrateur. L'envoi d'alarmes peut aussi 
etre archive dans une table des masques d'alarmes. Avantageusement. I'onsemblo dos informations contenues dans 
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le message peut aussi etre archive. 

[0046] L'annexe 2 presente un modele de filtre d'alarmes. L'annexe 3 presente les donnees dynamiques d'un filtre 
d'alarmes. 

[0047] Le module de calcul d'indicateur (MCI) calcule des indicateurs sur les equipements (ET) a administrer. Un 
5 indicateur est une equation dans laquelle des instances d'objets de gestion de base de d'informations (MIB snmp) sont 
introduites. Ces instances d'objets sont obtenues par ('interrogation (polling) sur les agents (snmp) fonctionnant sur 
chacun des systemes a administrer Le resultat de cette equation est compare a une valeur seuil ne devant pas etre 
depassee un certain nombre de fois pendant un certain laps de temps. Lorsque la valeur seuil est depassee. un certain 
nombre de fois pendant un certain laps de temps, une alarme est emise vers I'administrateur principal (AD). 
10 [0048] Prenons I'exemple d'un indicateur a instancier sur les equipements du domaine MIB2 comportant une periode 
d'interrogation de 60 secondes. Cet indicateur calcule ('utilisation de la bande passante d'une carte de reseau quel- 
conque a I'aide de I'equation: 

1$ (8*$- (if InOctets. 1 + ifOutOctets.1 ) /if Speed. 1 

Cette equation sera calculee sur chacun des equipements du domaine MIB2 toutes les minutes. Si. sur le systeme 
"A", le resultat excede la valeur 10 au moins deux fois en cinq minutes, une alarme sera envoyee a I'administrateur 
principal (AD). Et cette alarme sera percue par ce dernier comme provenant du systeme "A". 
20 [0049] Un indicateur comporte des operateurs simples tels que I'addition (+), la soustraction (-) : la multiplication (*) : 
la division (/) et des operateurs d'ensemble. Les operateurs d'ensemble permettent d'appliquer un operateur sur des 
series d'instances d'indicateurs. Ainsi. l'operateur: 

!SUM qui realise la somme d'une serie d'instances d'indicateurs, 
25 - !MOY qui realise une moyenne d'une serie d'indicateurs. 

!MAX qui recherche la valeur maximum parmi une serie d'indicateurs, 
!MIN qui recherche la valeur minimum parmi une serie d'indicateurs. 

Attention, les operateurs d'ensemble sont appliques a des systemes et non au temps. L'annexe 9 nous decrit quelques 

30 exemples d'equations simples utilisant les operateurs d'ensemble. De plus, un indicateur peut egalement comprendre 
un operateur delta note $- et un operateur d'indirection tempore! note &. L'operateur delta est defini tel que, a I'instant 
t. $-(x) = x(t) - x(t-T) ou I'attribut x de valeur x(t- T) est recueilli a I'instant (t - T) et ou la valeur $-(x) donne la difference 
entre x(t) et x(t- T). $- (x) correspond a un delta et $t a un delta(t). L'operateur d'indirection temporel permet de reutiliser 
un calcul deja effectue sur un equipement. Le module de calcul des instances (MCI) interroge le noyau pour initialiser 

35 ces parametres de fonctionnement. 

[0050] En fonctionnement, le module de configuration des modeles (MCM) notifie au module de calcul d'indicateurs 
(MCI) les modeles a instancier sur les equipements. Les donnees stockees dans le module de calcul d'indicateurs 
(MCI) sont les descriptions de modeles d'indicateurs (avec le nom du modele), les instanciations de chacun des indi- 
cateurs et des informations de fonctionnement comme, par exemple, le dernier resultat de I'instance. la date de la 

-to prochaine interrogation de I'instance, ...etc. 

[0051] Le resultat de I'instanciation d'indicateurs peut etre archive d'une part dans un fichier sur le disque dur a I'aide 
de I'emploi de la fonction "set". L'utilisateur selectionne nominativement les indicateurs qu'il veut journaliser (logger). 
Dans ce cas, I'administrateur peut le recuperer a I'aide d'un protocole de transfert de fichiers (FTP). D'autre part, le 
resultat de I'instanciation d'indicateurs est aussi stocke dans une table d'indicateurs accessible directement par une 

■*$ requete SNMP. 

[0052] Les informations concernant les indicateurs ainsi archives comportent la date, le modele de Tindicateur in- 
terroge, I'adresse (IP) de I'equipement interroge et le resultat du calcul de I'indicateur. Un fichier archive peut, par 
exemple, etre trace sous cette forme : Nov 27 11:44 1997:3:129.184.59.7:271.4268. Ce fichier doit etre interprets sous 
cette forme : le 27 novembre 1997, a 11h44, I'equipement 129.184.59.7 a ete interroge sur le modele 3 est le resultat 
so est 271.4268. 

[0053] Avantageusement. afin de limiter la taille du stockage des equations, les chaines de caracteres correspondant 
aux instances interrogees sont stockees dans un tableau et representees par des identificateurs. 
[0054] Remarquons que toutes les fonctions de calcul d'equations, de description de seuils, de definition de periodes 
de calcul, de frequence maximale de depassement de seuil, de sens de comparaison du resultat sont entierement 
55 configurables a distance et dynamiquement via le protocole snmp. 

[0055] L'annexe 5 presente un modele d'indicateur. L'annexe 6 presente les donnees dynamiques d'indicateurs. 
[0056] Lorsqu'un equipement ne repond plus aux sollicitations des modules de decouvertes (MD) et de calcul d'in- 
dicateurs (MCI), le module (MCG) chien de garde (watchdog) verifie si cette equipement a reellement disparu. En effet. 
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cet equipement n'a pas ete forcement supprime. Un equipement peut ne plus ne plus etre visibte pendant un certain 
laps de temps en raison des aleas lies au trafic du reseau ou parce que le reseau local d'entreprise (RLE) est surcharge. 
Le role du module chien de garde (MCG) est de le verifier. 

[0057] Quand, le module de decouverte (MD) ou le module de calcul d'indicateurs (MCI) previent le module chien 
5 de garde (MCG) de I'eventuelle disparition d'un equipement, le module de chien de garde (MCG) sollicite, a nouveau, 
cet equipement mais de maniere plus pressante. II envoie un message a I'equipement suppose disparu et attend une 
reponse pendant un temps tres long. II laisse beaucoup plus de temps a I'equipement pour repondre. Si I'equipement 
repond, le module chien de garde (MCG) ne signale rien et par defaut, les modules de decouverte (MD) et/ou le module 
de calcul d'indicateurs (MCI) supposent que I'equipement existe toujours. Si I'equipement ne repond pas : le module 
10 chien de garde envoie un nouveau message en laissant a I'equipement suppose disparu un temps de reponse encore 
plus long. Apres un certain nombre d'envois de messages, si I'equipement suppose disparu n'a toujours pas repondu 
aux differents messages : le module chien de garde (MCG) emet une alarme en direction de I'administrateur principal 
(AD) lui indiquant la disparition de cet equipement. Cette alarme est simulee comme provenant de I'equipement disparu. 
Ceci permet une valorisation de ('information et une simplification de visualisation au niveau de I'administrateur prin- 
ts cipal. Le module chien de garde (MCG) envoie des notifications au module de decouverte (MD), au noyau (N) et au 
module de configuration des modeles (MCM) de maniere a ce que I'equipement disparu soit supprime de leurs bases 
de donnees. 

[0058] Lorsqu'un equipement n'a pas repondu a la sollicitation du module de calcul d'indicateurs (MCI), mais que 
I'equipement repond a ('interrogation du module chien de garde, il est possible que des agents (snmp) aient ete mo- 

20 difies Une redecouverte du domaine de ce systeme est alors automatiquement demandee. 

[0059] Le module de securisation d'alarmes (MSA) permet de securiser les alarmes envoyees par le sous-adminis- 
trateur (COACH) vers I'administrateur principal (AD). Ce module fonctionne selon un mecanisme client-serveur, le 
serveur du module de securisation d'alarmes (sMSA) est attache a I'administrateur principal (AD) et le client du module 
de securisation d'alarmes est attache au module de filtrage d'alarmes (MFA). Lorsqu'uhe alarme est envoyee a I'ad- 

25 ministrateur elle est toujours accompagnee d'un message d'envoi envoye par le client (cMSA) et destine au serveur 
(sMSA). La reception de ce message d'envoi par le serveur (sMSA) implique automatiquement que I'administrateur 
ait regu ('alarme accompagnant ce message. Lorsque le serveur (sMSA) receptionne le message d'envoi, il envoie au 
client (cMSA) un message de confirmation de reception. Des reception du message de confirmation de reception, le 
client (cMSA) enleve les instances d'alarmes stockees dans le module de filtrage d'alarmes (MFA). Lorsque, apres un 

30 temps determine par avance, le client (cMSA) n'a pas regu de message de confirmation de reception, il renvoie I'alarme 
accompagnee d'un nouveau message d'envoi a I'administrateur principal, Le client (cMSA) recommence cette opera- 
tion jusqu'& ce qu'il regoive un message de confirmation de reception. 

[0060] La confirmation d'alarmes permet de garantir de maniere quasiment absolue la reception des alarmes par 
I'administrateur. Le fonctionnement global a encore ete ameliore par une fonction d'emission d'alarmes en bloc. Le 

35 module de securisation d'alarmes (MSA) a la possibility de ne pas envoyer pas instantanement les alarmes mais les 
archive puis les envoie, par paquet, a une frequence donnee. Les lignes de communication ne sont sollicitees que 
pendant cette periode. La frequence d'emission des alarmes est choisie lors du parametrage du module de securisation 
d'alarmes. Ce principe est particulierement interessant pour les lignes du Reseau Numerique a Integration de Service 
(RNIS) (Integrated Services Digital Network, ISDN) pour lesquelles I'ouverture d'une ligne prend du temps, et la fer- 

•*o meture s'effectue apres un delai. Avantageusement, pour augmenter encore la securisation de ces alarmes, la ligne 
est ouverte quelques secondes avant Penvoi des alarmes. 

[0061] Le module de configuration de modeles (MCM) permet d'indiquer dynamiquement aux modules de calcul 
d'indicateurs (MCI) et de filtre d'alarmes (MFA) : les indicateurs et les modeles de filtrage d'alarmes a appliquer sur 
chacun des equipements (ET) du sous-reseau. Lors de la decouverte d'un equipement, le module de decouverte (MD) 
-*5 envoie une notification au module de configuration des modeles (MCM), lui indiquant I'adresse du protocole internet 
(adresse IP) de I'equipement decouvert, ainsi que le domaine auquel il appartient. Le module de configuration des 
modeles (MCM) notifie, alors. I'indicateur, au module de calcul d'indicateurs (MCI) et le modele de filtre. au module de 
filtrage d'alarmes. 

[0062] Si . par exemple, un indicateur doit etre tnstancie sur les systemes MIB2, pour tous les systemes decouverts, 
so ie module de configuration des modeles (MCM) va indiquer I'instanciation de cet indicateur au module de calcul d'in- 
dicateurs (MCI). 

[0063] Le module de configuration de modeles (MCM) comporte les correspondances entre les domaines et leurs 
modeles (de filtre et d'indicateur). 

[0064] Le module de configuration de modeles (MCM) est compose d'une partie d'initialisation et d'une partie de 
ss mise a jour en fonctionnement. Lors de ('initialisation, les descriptions d'indicateurs et de modeles de filtre existant 
dans la base de donnees du noyau (N) sont detruites. Ces descriptions sont par la suite lues dans un fichier d'initiali- 
sation (confmod.ini). 

[0065] Un exemple d'un fichier de configuration (confmod.ini) contenant un indicateur est decrit en annexe 4. Un 
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indicateur est defini par differents champs: 


Champ 

Definition 

Type 

IND pour un modele d'INDicateurs 

Id 

Index d'indicateur (generation automatique) 

Nom 

Nom de I'indicateur 

Domaine 

Regroupement d'equipements administres trouves 


par leur adresse en domaines identifiables par 5 


requetes "Get" envoyees par le sous-administrateur 


(COACH). Cela signifie qu'aujourd'hui, il existe au 


plus 5 identifieurs d'objets (Oids) possibles pour 


definir un domaine 

Equation 

Equation de I'indicateur 

T polling 

Periode d'interrogation ou de construction de 


I'indicateur 

Seuil 

Seuil de decision pour remission d'une alarme 

Apparition 

Nombre d'apparitions de la valeur seuil apres 


laquelle il y a emission d'alarmes 

Periode 

Periode au-dela de laquelle le nombre 


d'apparitions des x valeurs de seuil est remis a 


zero 

Sens de comparaison 

Sens de comparaison entre le seuil defini et le 


resultat de I'equation pour decrire un 


depassement. II peut etre > : < t =, ou ! = 

Booleen de Log de 

Ce champ permet de creer un historique (logguer) sur I'indicateur en phase de 

I'indicateur 

journalisation 


generate. II prend la valeur "LOG" pour logguer 


I'indicateur ou "NLOG" pour ne jamais logguer 


I'indicateur 


[0066] Un exemple d'un fichier de configuration (confmod.ini) contenant un modele de filtre d'alarmes est decrit en 
annexe 1. Un modele de filtre d'alarmes est defini par differents champs: 



Champ 

Definition 


Type 

FIL pour un modele de FILtre 

40 

id 

Index du modele de filtre (generation automatique) 


Nom 

Nom du filtre 


Domaine 

Regroupement des equipements administres trouves 
par leur adresse en domaines identifiable par 5 

45 


requetes "Get" envoyees par le sous-administrateur 


COACH 


Enterprise 

Champ "enterprise" de I'alarme a filtrer 


Generic 

Champ "generique" de I'alarme a filtrer 


Specific 

Champ "speciftque" de I'alarme a filtrer 

50 

Apparition 

Nombre d'apparitions de I'alarme apres laquelle, il 
y a reemission d'une alarme vers I'administrateur 


Periode 

Periode au-dela de laquelle sans reception 
d'alarmes de ce type, le nombre d'apparition 
d'alarmes est remis a zero. 

55 




[0067] Apres initialisation, le module de configuration des modeles (MCM) interroge le noyau afin de connaitre tous 
les equipements decouverts ainsi que leurs domaines. Puis, il envoie des notifications au module de filtrage d'alarmes 
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(MFA) et au module de calcul d'indicateurs (MCI) : leur indiquant les modetes a instancier selon les adresses du pro- 
tocole internet (adresse IP) des equipements decouverts. 

[0068] En fonctionnement courant, le module de configuration des modeles (MCM) est k I'ecoute du support (socket) 
de communication du noyau et attend des changements. Ces changements peuvent concerner soit I'ajout ou la sup- 
s pression d'un equipement sur le reseau ; soit des modifications d'indicateurs ou de modeles de filtre. 

[0069] D'autres modifications a la portee de I'homme de metier font egalement partie de I'esprit de ('invention. 


w 
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ANNEXE 1 


# SECTION de description des filtres de traps 

w 

# 

# Format de la Ligne de description 

1S & I Type I nom du trap I entreprise I Generic I Specific I limite en nb traps I periode I 

# 

20 # AXA/COACH/unix/trapFilters 

# 

FIL 1 alix-fs-ofliU 2 Bull. 1 18 6 4 1 60 
2s FIL 2 alix-fs-error 2 1 3 .6. 1.4. 1. 107. 114 6 5 100 6 

FIL 3 alix-uxLoginSession-setFailed 2 Bull. 1 18 6 33 3 30 

FEL 4 trap_essai_4 1.3 6.1.4 1 107 144 6 7 3 10 
30 FIL 5 trap_essai_5 1 1.3.6.1.4.107.144 6 8 2 10 

FIL 6 alix-Fs-nfull 2 Bull. 1 18 6 9 1 60 

FIL 7 alix-fs-error 2 Bull. 1 18 6 10 1 60 

35 

FEL 8 alix-uxLoginSession-setFailed 2 Bull. 118 6 11 3 30 
FIL 9 trap_essai_4 1 1.3.6.1.4.1.107.144 6 12 3 10 
FIL 10 trap essai 5 I 1.3 .6.1.4.1.107.144 6 13 2 10 

40 ~ 

FIL 1 1 aUx-fs-nruU 2 Bull. 1 18 6 14 1 60 

FEL I2alix_fs_error 2 Bull. 1 1 8 6 1 5 1 60 
4S FEL 13 alix-uxLoginSession-setFailed 2 Bull. 1 18 6 133 3 30 

FIL 14 trap_essai_4 1 1.3.6.1.4.1,107.1446 17 3 10 

FEL 15 trap_essai_5 1 1.3 6 1.4.1 107.144 6 18 2 10 
so FIL 16 alix-fs-nfuU2Bull.H8 6 19 1 60 

FIL 17 alix_fs_error 2 Bull. 1 18 6 20 1 60 

FEL 18 alix-uxLoginSession-SetFailed 2 Bull. 1 18 6 21 1 3 30 
55 FIL 19 trap_essai_4 1 1.3 .6.1.4.1.107.144 6 212 3 10 
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FFL 20 trap_essai_5 I 1.3.6. 1.4. 1 . 107. 144 6 213 2 10 
5 FIL 2 1 alix Jsjifiill 2 Bull. 1 18 6 24 1 60 

FIL 22 alix-fs-error 2 Bull. 1 18 6 25 1 60 

FIL 23 aiix-uxLoginSession-setFailed 2 Bull. 1 18 6 233 3 30 
w FIL 24 trap_essai_4 1 1.3.6 I 4 K 107. 144 6 27 3 10 

FIL 25 trap_essai_ 5 1 1.3.6.1.4.1.107.144 6 28 2 10 

FIL 26 alix-fs-nfiill 2 Bull. 1 18 6 29 1 60 
75 FIL 27 alix-fs-error 2 Bull 1 1 8 6 30 1 60 

FLL 28 alix-uxLoginSession-setFailed 2 Bull. 1 18 6 3 1 1 3 30 

FIL 29 trap_essai_4 I 1 .3.6. 1 .4. 1 . 1 07 144 6 312 3 10 

20 

FIL 30 trap_essai_5 1 1 3 6 1 4. 1 107 144 6 313 2 10 

25 
30 
35 
40 
45 
SO 
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Modeles de filtres 


cfgFilterTable OBJECT-TYPE 

SYNTAX SEQUENCE OF CfgFilterEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 

"Table de configuration des modeles de filtres " 
:.= { CoachCfg2 } 

CfgFilterEntry OBJECT-TYPE 

SYNTAX CfgFilterEntry 

ACCESS not-accessible 
STATUS mandatory 

DESCRIPTION 

"Une entree (ligne) dans la table des modeles de filtres." 

INDEX { cfgFilterld } 

::= { cfgFilterTable 1 } 

CfgFilterEntry ::= 
SEQUENCE { 
cfgFilterld 

INTEGER, 
cfgFilterLabel 

OCTET STRING. 
cfgFilterDomain 

INTEGER, 
cfgFilterEnterprise 

OBJECT IDENTIFIER. 
cfgFilterGeneric 

INTEGER, 
cfgFilterspecific 

INTEGER, 
cfgFilterCptMax 

INTEGER, 
cfgFilterPeriodValid 

INTEGER 

} 
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cfgFilterld OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

"La valeur de cet attribut identifie de maniere unique une entree dans 
la table des modeles de filtres." 
{ cfgFilterEntry 1 } 

cfgFilterLabel OBJECT-TYPE 
SYNTAX OCTET STRING 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Description textuelle d'un modele de filtre." 
::= { cfgFilterEntry 2 } 

cfgFilterDomain OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Identifiant du domaine auquel appartient le modele de filtre." 
::= { cfgFilterEntry 3 } 

cfgFilterEnterprise OBJECT-TYPE 
SYNTAX OCTET STRING 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Object Identifier de I'entreprise du trap." 
::= { cfgFilterEntry 4 } 

cfgFUterGeneric OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Numero generique du trap," 
( cfgFilterEntry 5 } 

cfgFilterSpecific OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-write 
STATUS mandatory 
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DESCRIPTION 

"Numero specifique du trap." 
::= { cfgFilterEntry 6 } 

fgFilterCptMax OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Nombre de fois ou le trap doit etre recu durant <cfgFUterPeriodValid 
pour qu'U soit transmis." 
::= { cfgFilterEntry 7 } 

fgFilterPeriodValid OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Periode (en secondes) durant laquelle le trap doit etre recu 

<cfgFilterCptMax> fois pour etre transmis." 
::= { cfgFilterEntry 8 } 
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ANNEXE 3 


Donnees de filtres 


filterTable OBJECT-TYPE 

SYNTAX SEQUENCE OF FilterEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 

"Table associant un modele de filtre a une machine." 
::= { CoachData2 } 

filterEntry OBJECT-TYPE 
SYNTAX FilterEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 

"Une entree (ligne dans la table des filtres. " 
INDEX { filterld, filter Ip Address } 
;:= { filterTable 1 } 

FilterEntry ::= 
SEQUENCE { 
fiJterld 

INTEGER, 
filterlpAddress 

IpAddress 

} 

filterld OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

"Identifiant du filtre (le meme que <cfgFilterId>), la valeur de cet 
attribut identifie de maniere unique avec <filterIpAddress> une entree 
dans la table des filtres. " 
:= { filterEntry 1 } 
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filterlpAddress OBJECT-TYPE 
SYNTAX IpAddress 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

"Adresse IP de la machine eoiet trice du trap, la valeur de cet attribut 
identifie de maniere unique avec <filterld> une entree dans la table des 
nitres." 

::= { filterEntry 2 } 
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ANNEXE 4 


10 


IS 


20 


25 
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# SECTION de description des indicateurs 


# type . 

# Id : 
#Nom : 

# Domaine : 

# Equatioa : 

# T polling : 

# Seuil : 

# Apparition 


IND I FIL respectivement rNDicateurs ou FILtre 
index d'indicateur (generation automatique) 
nom de I'indicateur 

regroupemeot de systemes manages trouves par leur 
adresse en domauies identifiables par 5 requetes get 
envoyees par COACH 

equation de I'indicateur 

periode de polling ou de construction de I'indicateur 

seuil de decision pour 1'emission d'un trap 

nombre d'apparitions de la valeur de seuil apres laquelle, 
il y a emission de traps 


sur quelle periode apparaissent les x valeurs de seuil 
sens de comparaison entre le seuil et le resultat 
indique si I'indicateur devra etre loggue ou non 


# Periode : 

# Sens de comparaison : 

# Log : 
# 

# Format de la ligne de description 

# I type I Id I Nom I Domaine I Equation I T polling I seuil I x fois I en T secondes 
sens du test I log 

AXA/COACH/interaet/indicators 

# 

# % d'utilisation de la bande passante sur Tintertace 
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IND 1 ifUtilizatiooBandWith 2(((8*S(iiInOctets. 1+ifOutOctets. 1 ))/St)/ifSpeed. 1)* 100 
600 10 I 1200 > LOG 

# % d'utilisation de la bande passante sur le segment 

IND 2 iOJtUizationBandWithAll 3 I SLTVi(ifUtilizationBandWith) 1210 10 1 3 3600 > 
LOG 

U Debit de rejection de paquets en entree et sortie sur le segment 

IND 3 tfDiscards 2 S-(iflnDiscards. 1+ifOutDiscards 1) 120 1 I 120 > LOG 

# Somme des debits de rejection de paquets en entree et sortie sur le segment 
IND 4i£DiscardsAll 3 I SUM(ifDiscards) 320 3 I 320 > LOG 

# Longueur de la file d'attente des paquets en sortie sur 1'interface 
IND 5 coachlfOutQlen 2 ifOutQLen. 1 330 5 1 330 > LOG 

# Somrne des Longueurs de la file d'attente des paquets en sortie sur toutes les interfaces 
du segment 

IND 6 coachlfOutQLenAll 3 i SUM(coachlfOutQLen) 670 50 1 670 > LOG 

# Nombre de paquets retransmis sur 1'interface 

IND 7 coachcpRetransSegs 2 tcpRetransSegs 0 340 5 1 340 > LOG 

# Debit d'erreurs sur Tinterface 

IND 8 ifErrors 2 (S(ifInErrors. 1+ifOutErrors. l)$t) 290 5 I 290 > LOG 

# Debit d'erreurs sur le segment 

IND 9 ifErrorsSUM 3 !SUM(ifErrors) 620 2 1 620 > LOG 

# Debit moyen d'erreurs sur toutes les interfaces du segment 

IND 10 ifErrorsMOY 3 (!MOY(i£Errors)* 100) 630 5 1 630 > LOG 

# Debit unicast sur 1'interface en entree et en sortie 

IND 1 1 ifUcast Packets 2 (iflnUcastPkts. l+ifOutUcastPkts.l)$t 280 5 I 280 > LOG 

# Debit multicast sur 1'interface en entree et en sortie 

IND 12 ifNUPackets 2 (iflnNUcastPkts. KifOutNUcastPkts. I)$t280 5 1 280 >NLOG 

# % d'erreurs sur 1'interface par rapport au total des paquets emis ou re^us 

rND 13 ifErrorsRatio 2 (&ifErrors/(&if!nPackets+&ifOutPackets)) * 100 570 5 1570 > 
NLOG 

# % moyen sur le segment des erreurs sur toutes les interfaces du segment 
LND 14 ifErrorsRatioLinkMOY 3 'MOY(ifErrorsRatio) 1220 5 1 1220 > LOG 
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# % Somme des pourcentages d'erreurs sur toutes les interfaces des liens 

[ND 15 IfErrorsRatioLinkSUM 3 !SUM(UErrorsRatio) 1220 20 i 1220 > LOG 

# Quantite d'erreurs d'en-tete et d'adresse sur I'interface Utiliser pour calculer 
ipInputErrorsPercent 

[ND 16 ipInputErrors 2$-(ip[nHdrErrors.0+ip[nAddrErrors.0) 650 5 1 650 > LOG 

# % d'erreurs d'en-tete et d'adresse sur I'interface 

[ND 17 ipInputErrorsPercent 2 (&ipInputErrors/($-(iplnDelivers 0)))* 100 650 5 1 650 
>LOG 

# Somme des pourcentages d'erreurs d'en-tete et d'adresse sur ('interface 

[ND 18 ipInputErrorsPercentOnLink 3 !SUM(ipInputErrorsPercent) 300 5 1 300 > LOG 


# lndisponibilite d'une machine 

FND lQNoDisponibility 2-$t/($-(sysUpTime 0)) 100 1 1 300 > LOG 

# Somme de l'indisponibilite pour l'ensemble des machines du segment 

FND 20 NoDisponibilityOoLink 3 !SUM(NoDispooibiity) 150 100 1 300 > LOG 

# 21/10/97 20:17 fichier : CONFMOD DOC#version DRAFT 


.09S1155A1J 
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ANNEXE 5 


Coach- MTB DEFINITIONS := BEGIN 


bull 

gam 

Coach 

CoachCfg 

CoachData 


OBJECT IDENTIFIER ::={ enterprises 107 > 
OBJECT IDENTIFIER ::={ bull 146 } 


OBJECT IDENTIFIER :={ gam 1 } 


OBJECT IDENTIFIER ::={ Coach 1 } 


OBJECT IDENTIFIER ::={ Coach 2 } 


CoachSystem OBJECT IDENTIFIER ::={ Coach 3 } 


Configuration de Coach 


- Modeles d'indicateurs 


cfglndicatorTable OBJECT-TYPE 

SYNTAX SEQUENCE OF CfglndicatorEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 

"Table de configuration des modeles d'indicateurs." 
::= { CoachCfg 1 } 

CfglndicatorEntry OBJECT-TYPE 
SYNTAX CfglndicatorEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 

"Une entree (ligne) dans la table des modeles d'indicateurs." 
INDEX { cfglndicatorld } 
= { cfglndicatorTable 1 } 
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ComparaisonType ::= INTEGER {equal(0),less(l),greater(2)} 


10 


CfglndicatorEntry ::= 
SEQUENCE { 
cfglndicatorld 

INTEGER, 
cfglndicatorLabel 

OCTET STRING, 
cfglndicatorDomain 
INTEGER, 

is cfglndicatorEquation 

OCTET STRING, 
cfglndicatorPeriodPolling 

INTEGER, 
cfglndicatorThreeshold 

INTEGER, 
cfglndicatorCptMax 

INTEGER, 
cfglndicatorPeriod Valid 
25 INTEGER, 
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cfglndicatorComparaison 
ComparaisonType 

} 

cfglndicatorld OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

"La valeur de cet attribut identifie de maniere unique une entree dans 
la table des modeles d'indicateurs." 
::= { CfglndicatorEntry 1 } 

cfglndicatorLabel OBJECT-TYPE 
SYNTAX OCTET STRING 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Description textuelle d'un modele d'indicateur." 
::= { CfglndicatorEntry 2 } 


so cfglndicatorDomain OBJECT-TYPE 

SYNTAX INTEGER 
ACCESS read-write 
STATUS mandatory 
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DESCRIPTION 

"Identifiant du domaine auquel appartient le modele d'mdicateur." 
{ cfglndicatorEatry 3 } 

cfglndicatorEquation OBJECT-TYPE 
SYNTAX OCTET STRING 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Equation arithmetique decrivant le modele d'indicateur " 
::= { cfglndicatorEntry 4 } 

cfglndicatorPeriodPolling OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read- write 
STATUS mandatory 
DESCRIPTION 

"Periode (en secondes) a laqueUe l'indicateur va etre calcule." 
::= { cfglndicatorEntry 5 } 

cfglndicatorThreeshold OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Seuil que doit depasser L'indicateur <cfglndicatorCptMax> fois durant 
<cfgIndicatorPeriodValid> pour qu'une alarme soit envoyee." 
: := { cfglndicatorEntry 6 } 

cfglndicatorCptMax OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Nombre de fois ou l'indicateur doit depasser <cfg!ndicatorThreeshold> 
durant <cfgIndicatorPeriodVaJid> pour qu'une alarme soit envoyee " 
::= { cfglndicatorEntry 7 } 

cfglndicatorPeriodValid OBJECT-TYPE 

SYNTAX rNTEGER 

ACCESS read-write 

STATUS mandatory 

DESCRIPTION 

"Periode (en secondes) durant laquelle l'indicateur doit depasser 
<cfg!ndicatorCptMax> fois <cfgIndicatorThreeshold> pour qu'une alarme 
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soit envoyee." 
::= { cfglndicatorEntry 8 } 

5 

cfglndicatorComparaison OBJECT-TYPE 
SYNTAX ComparaisonType 
ACCESS read-write 
STATUS mandatory 
10 DESCRIPTION 

"Type de comparaison entre le seuil <ct*gIndicatorThreeshold> et 
le resultat de I'equation <LndicatorResult> " 
y- { cfglndicatorEntry 9 } 
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ANNEXE 6 


— Donnees d'indicateurs 


indicator-Table OBJECT-TYPE 

SYNTAX SEQUENCE OF IndicatorEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 

"Table de resultats de calculs d'indicateurs." 
::= { CoachData i } 

IndicatorEntry OBJECT-TYPE 
SYNTAX IndicatorEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 

"Une entree (ligne) dans la table des indicateurs " 
rNDEX { indicatorld, indicatorlpAddress } 
::= { indicatorTable I \ 

IndicatorEntry ::= 
SEQUENCE { 
indicatorld 

INTEGER. 
indicatorlpAddress 
IpAddress, 
indicatorResult 

INTEGER 

} 

indicatorld OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

"Identifiant de I'indicateur (le meme que <cfgIndicatorId>), la valeur 
de cet attribut identifie de maniere unique avec <indicatorIpAddress> 
une entree dans la table des indicateurs. " 
::= { indicatorEntry I } 

indicatorlpAddress OBJECT-TYTE 
SYNTAX IpAddress 
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ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

"Adresse IP de la machine sur lequel l'indicateur est calcule, la valeur 
de cet attribut identifie de maniere unique avec <indicatorId> une 
entree dans la table des indicateurs." 
;:= { indicatorEntry 2 } 

indicatorResult OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

"Resultat du calcul de l'indicateur." 
.:= { indicatorEntry 3 | 
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ANNEXE 7 


- Configuration de la decouverte 


fgDiscovery OBJECT IDENTtFIER ::={ CoachCfg 4 } 

;fgDiscoverPeriod OBJECT-TYTE 
SYNTAX INTEGER 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Periode (en secondes) a laquelle une decouverte est declenchee." 
{ cfgDiscovery 1 } 


fgDiscoverPenodlCMP OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Penode (en secondes) de I'lCMP renforce." 
::- { cfgDiscoveiy 2 } 


fgDiscoverBroadcast OBJECT-TYPE 
SYNTAX IpAddress 
ACCESS read-wnte 
STATUS mandatory 
DESCRIPTION 

"Adresse broadcast du sous-reseau." 
::= { cfgDiscovery 3 } 


fgDiscoverDomainAtNextTime OBJECT-TYPE 
SYNTAX INTEGER { 
yes(l), 
no (2) 

} 

ACCESS read- write 
STATUS mandatory 
DESCRIPTION 

"Redecouverte ou non des domaines au prochain Discovery 
{ cfgDiscovery 4 } 
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cfgDiscoverMaxDisc OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Nombre maximum de mauvaises clecouvenes." 
= { cfgDiscovery 5 } 


cfgDiscoverMaxICMP OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Nombre maximum de mauvaises reponses I CMP 
::= { cfgDiscovery 6 } 


cfgDiscoverMinMachine OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-write 
30 STATUS mandatory 

DESCRIPTION 

"Nombre minimum de machines sur ie sous-reseau." 
::= { cfgDiscovery 7 } 


cfgDiscoverTimeOut OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

'Time_out de renvoi 1CMP " 
::= { cfgDiscovery 8 } 


cfgDiscoverTimeOutlCMP OBJECT-TYPE 
SYNTAX INTEGER { 
50 yes (I), 

no (2) 


ACCESS read-write 
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STATUS mandatory 
DESCRIPTION 

"Politique ICMP renforce tors de depassement de ttme_out u 
::= { cfgDiscovery 9 } 
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ANNEXE 8 

5 

— Donnees de decouvene 


discoverTable OBJECT-TYPE 

SYNTAX SEQUENCE OF DiscoverEntn, 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 

"Table de decouverte des machines gerees par Coach " 
::= { CoachData 3 } 

discoverEntry OBJECT-TYPE 
SYNTAX DiscoverEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 

"Une entree (ligne) dans la table de decouverte." 
INDEX { discoverlpAddress } 
: := { discoverTable 1 } 


30 

DiscoverEntry :: = 
SEQUENCE { 

discoverlpAddress 
IpAddress, 

35 discoverDomainld 

INTEGER 

} 


discoverlpAddress OBJECT-TYPE 

SYNTAX IpAddress 

ACCESS read-write 

STATUS mandatory 

DESCRIPTION 

"Adresse IP de la machine, la valeur dc cet attribut indentitle 
maniere unique une entree dans la table de decouverte." 

::= { discoverEntry I } 

discoverDomainld OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-write 
STATUS mandatory 
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DESCRIPTION 

"Identifiant du domaine auquel appartient la machine/ 1 
::= { disco verEntry 2 } 
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[0070] ANNEXE 9 
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1. Procede d'administration d'un reseau et d'un systeme caracterise en ce qu'il comprend au moins un sous-admi- 
nistrateur (COACH) situe dans I'arbre de contenance entre un administrateur principal (AD) et les equipements 
du reseau. le sous-administrateur etant localise sur le reseau local d'entreprise (RLE)., administrant un sous-reseau 
et comprenant differents modules qui communiquent entre eux et avec un administrateur principal (AD) par I'in- 
termediaire d'un noyau (N) ; les modules interrogeant les equipements du sous-reseau et recevant les alarmes 
lancees par les agents (SNMP) fonctionnant sur les equipements du sous-reseau, )e procede etant compose de 
plusieurs etapes : 


45 


50 
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une etape pendant laquelle un module de decouverte (MD) interroge tous les equipements (ET) possibles du 
sous-reseau. 

une etape de recherche de domaine par le module de decouverte (MD), lorsqu'un equipement repond a ('in- 
terrogation (SNMP), 

une etape pendant laquelle le module de decouverte (MD) envoie une notification a un module de configuration 
des modeles (MCM) lui indiquant I'adresse internet (IP) de I'equipement decouvert et le domaine auquel I'equi- 
pement decouvert appartienL 

une etape pendant laquelle le module de configuration des modeles (MCM) notifie a un module de calcul 
d'indicateurs (MCI), I'indicateur a instancier sur I'equipement et a un module de filtrage d'alarmes (MFA) le 
modele de filtre a instancier sur I'equipement. 

Procede d'administration d'un reseau et d'un systeme selon la revendication ^, caracterise en ce qu'a chaque 
nouvelle etape de decouverte des equipements du sous-reseau, le module de decouverte (MD) met a jour les 
bases de donnees du noyau (N) et du module de configuration des modeles (MCM) contenant la liste des equi- 
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pements et de leurs domaines. 

3. Procede d'administration d*un reseau et d'un systeme selon la revendication 1 : caracterise en ce que toutes les 
alarmes emises par les differents modules sont envoyees a I'administrateur principal (AD) via le module de secu- 

5 risation d'alarmes (MSA), ladite alarme etant accompagnee d'un message d'envoi destine au serveur du module 

de securisation d'alarmes (sMSA). 

4. Procede d'administration d'un reseau et d'un systeme selon la revendication 3. caracterise en ce qu'il est compose : 

io - d'une etape de reception de Talarme par I'administrateur principal (AD) et de reception dudit message d'envoi 

par le serveur du module de securisation d'alarmes (sMSA)., 

d'une etape d'envoi d'un message de confirmation de reception par le serveur du module de securisation 
d'alarmes (sMSA) au client du module de securisation d'alarmes (cMSA), 

d'une etape de reception du message de confirmation de reception par le client du module de securisation 
*5 d'alarmes (cMSA), 

d'une etape de mise a jour des instances d'alarmes stockees dans le module de filtrage d'alarmes (MFA). 

5. Procede d'admi nitration d'un reseau et d'un systeme selon la revendication 1 : caracterise en ce lorsque le client 
du module de o„ ..irmation d'alarmes (MCA) n'a pas recu le message de confirmation de reception, il renvoie. 

20 apres un temps determine. I'alarme a I'administrateur principal (AD), I'alarme etant accompagnee d'un message 

d'envoi destine au serveur du module de securisation d'alarmes (sMSA). 

6. Procede d'administration d'un reseau et d'un systeme selon la revendication 1, caracterise en ce que lorsque le 
module de calcul d'indicateurs (MCI) ou le module de decouverte (MD) n'obtient pas de reponse a une requete 

25 e nvoyee a un equipement du sous-reseau, le module de calcul d'indicateurs (MCI) ou le module de decouverte 

(MD) envoie un message a un module chien de garde (MCG), le module chien de garde (MCG) interrogeant 
I'equipement suppose disparu et attendant de maniere plus longue, une reponse. 

7. Procede d'administration d'un reseau et d'un systeme selon la revendication 6 ; caracterise en ce que lorsque, 
20 apres un temps determine, le module chien de garde (MCG) n'obtient pas de reponse de I'equipement suppose 

disparu, 1'quipement est supprime de la base de donnees du noyau (N), de la base de donnees du module de 
decouverte (MD) et de la base de donnees du module de configuration des domaines (MCM), le module chien de 
garde (MCG) envoyant une alarme a I'administrateur principal (AD), lui indiquant la disparition de I'equipement. 
I'alarme etant percue par I'administrateur comme provenant de I'equipement a travers le module de securisation 
35 et envoyee en utilisant le module de securisation. 

8. Procede d'administration d'un reseau et d'un systeme selon la revendication 6, caracterise en ce que lorsque le 
module chien de garde (MCG) obtient une reponse de I'equipement suppose disparu, il demande la redecouverte 
des domaines si la demande a ete emise par le module de calcul d'indicateur. 

40 

9. Systeme d'administration d'un reseau et d'un systeme par un administrateur principal communiquant avec des 
equipements (ET) & travers un reseau grande distance (WAN) et des reseaux locaux d'entreprises (RLE) carac- 
terise en ce qu'il comprend au moins un sous-administrateur (COACH) localise sur le reseau local d'entreprise 
(RLE) et administre par I'administrateur principal (AD), le sous-administrateur (COACH) comportant des moyens 

15 d'interroger les equipements du reseau local d'entreprise (RLE), de filtrer et de stocker les alarmes lancees par 

les agents (snmp) fonctionnant sur les equipements du reseau, des moyens de securiser les alarmes envoyees 
a I'administrateur principal (AD) et un moyen de dialogue avec I'administrateur principal et entre les differents 
moyens. 

50 10. Systeme d'administration d'un reseau et d'un systeme selon la revendication 9, caracterise en ce que le moyen 
de dialogue est constitue d'un noyau (N) dialoguant avec I'administrateur principal (AD) et permettant le dialogue 
entre les differents modules composant ledit systeme, 

11. Systeme d'administration d'un reseau et d'un systeme selon la revendication 9, caracterise en ce que les moyens 
55 d'interroger les equipements du reseau local d'entreprise (RLE), de filtrer et de stocker les alarmes lancees par 

les agents (snmp) fonctionnant sur les equipements du reseau sont constitues 

d'un module de decouverte (MD) decouvrant les equipements (ET) du sous-reseau & administrer et classant 
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lesdits equipements dans des domaines en fonction des types d'agents qui y sont installes. Ce module de 
decouverte amplifie la fonction de decouverte de I'administrateur central, par une precision accrue, une de- 
couverte plus rapide et une economie considerable en bande passante. 

d'un module de configuration de modeles (MCM) comportant des modeles de filtre d'alarmes et des indicateurs 
5 pouvant etre automatiquement instancies sur les equipements du sous-reseau, chaque indicateur etant as- 

socie a une periode d'interrogation, 

d'un module de caicul d'indicateurs (MCI) calculant le resultat de ('application d'un indicateur a un equipement, 
I'indicateur etant defini pour le domaine auquel I'equipement apparttent, le resultat de cette application etant 
compare a une valeur seuil ne devant pas etre depassee un certain nombre de fois, pendant un certain laps 
10 de temps. 

d'un module de filtrage d'alarmes (MFA) recevant les alarmes envoyees par les agents (snmp) fonctionnant 
sur les equipements du sous-reseau, puis, selectionnant une partie desdites alarmes a I'aide d'un filtre defini 
pour un domaine donne, lesdites alarmes selectionnees etant re-emises vers I'administrateur principal (AD), 

'5 12. Systeme d'administration d'un reseau et d'un systeme selon la revendication 9, caracterise en ce que les moyens 
de securiser les alarmes envoyees a I'administrateur principal (AD) sont constitues : 

d'un module de chien de garde (MCG) qui. lorsqu'un module le lui demande, verifie ('existence d'un equipement 
par renvoi repete d'appels, si I'equipement disparu n'a pas repondu k un nombre predefini d'appels. ledit 
20 module chien de garde (MCG) envoie une alarme a I'administrateur principal (AD) qui sera percue par ce 

dernier comme provenant de I'equipement disparu, 

d'un module de securisation d'alarmes (MSA) fonctionnant selon le mecanisme client-serveur, le client (cMSA), 
lors de ('envoi d'au moins une alarme a I'administrateur, attendant un message de confirmation du serveur 
(sMSA) localise sur I'administrateur principal (AD), ledit serveur (sMSA). apres reception dudit message d'en- 
25 voi, envoyant un message de confirmation de reception au client (cMSA), le client renvoyant I'alarme et un 

autre message d'envoi a administrateur lorsque, apres un temps determine, le message de confirmation de 
reception n'est pas receptionne par le client. 

13. Systeme d'administration d'un reseau et d'un systeme selon la revendication 9, caracterise en ce que lorsque la 
30 valeur seuil est depassee un certain nombre de fois pendant un certain laps de temps, le module de caicul d'in- 
dicateurs (MCI) emet une alarme vers I'administrateur principal (AD), ladite alarme etant pergue par I'administrateur 
principal comme etant emise par I'equipement dont I'instanciation a ete effectuee. 

14. Systeme d'administration d'un reseau et d'un systeme selon la revendication 9, caracterise en ce qu'un indicateur 
35 est une equation appliquee a des instances d'objets d'une base de gestion d'informations (MIB), les instances 

etant obtenues par une interrogation des agents (SNMP) fonctionnant sur chacun des equipements du sous- 
reseau. 

15. Systeme d'administration d'un reseau et d'un systeme selon la revendication 9, caracterise en ce que le resultat 
•to d'un indicateur et/ou une liste des alarmes envoyees peut etre stocke dans un fichier archive sur le disque dur. 

16. Systeme d'administration d'un reseau et d'un systeme selon la revendication 9, caracterise en ce que le parame- 
trage des filtres d'alarmes s'effectue soit par un fichier d'initialisation soit via le protocole snmp 

17. Systeme d'administration d'un reseau et d'un systeme selon la revendication 9, caracterise en ce que les alarmes 
a envoyer sont accumulees par le module de confirmation d'alarmes afin de les envoyer groupees. par paquet, a 
une frequence donnee. 

18. Systeme d'administration d'un reseau et d'un systeme selon la revendication 9, caracterise en ce qu'un modele 
50 de filtre d'alarmes contient une description de I'alarme a reconnaitre et un nombre maximal d'occurrence d'alarmes 

avant lequel une autre alarme est emise vers I'administrateur principal (AD), si ledit nombre maximal d'occurrence 
d'alarmes est recu pendant une certaine periode. 

19. Systeme d'administration d'un reseau et d'un systeme selon la revendication 9, caracterise en ce que les differents 
55 modules interrogent le noyau (N) pour initialiser leurs parametres de fonctionnement. 

20. Systeme d'administration d'un reseau et d'un systeme selon la revendication 9, caracterise en ce que le noyau 
(N) gere une base de donnees contenant toutes les instances de la base de gestion d'informations (MIB). ledit 
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noyau comportant au moins deux supports (sockets) de communication et une interface commune de gestion de 
la communication avec les modules. 

21. Systeme d'administration d'un reseau et d'un systeme selon la revendication 9, caracterise en ce que les para- 
s metres d'initialisation du module de decouverte (MD) comportent la periode espagant deux decouvertes. te nombre 

minimum de systemes a decouvrir et le masque du protocole internet (IP) determinant I'etendue du reseau a 
decouvrir. 

22. Systeme d'administration d'un reseau et d'un systeme selon la revendication 9 : caracterise en ce qu'un equipement 
io (ET) decouvert est classe dans un ou plusieurs domaines en fonction de ses reponses aux interrogations effec- 

tuees sur chaque ensemble d'instances d'objets de la base de gestion d'informations (MIB) definissant un domaine. 
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